majit: retarget bare assertion-raise blocks instead of widening the pass - #1208

Follow-up to #1206, addressing the Codex parity review's §1 finding on that PR and the P1 on the first revision of this one.

The finding

#1206 taught remove_assertion_errors to follow a one-block indirection. Codex objected twice, and both times correctly:

"accept a single-entry intermediate block" is broader than PyPy's direct-only condition (exit.target is graph.exceptblock). It can remove a conditional edge whose target block contains operations before raising AssertionError. join_blocks cannot justify this: it requires the predecessor to be unconditional with one exit (simplify.py:283-286), which a branch block is not.

Collapse or retarget the raise block in the corresponding simplification phase, then keep this pass's predicate literal, rather than retaining a second implementation with different eligibility rules.

The fix

remove_assertion_errors goes back to upstream's literal predicate. A new retarget_assert_raise_blocks runs immediately before it in simplify_lowered_graph and points an edge whose target exists only to raise the implicit AssertionError straight at exceptblock — where the flow space puts it upstream (flowcontext.py _implicit_), which is why the upstream predicate can be literal in the first place. The bypassed block keeps its exits and falls out as unreachable, the way eliminate_empty_blocks (simplify.py:52-69) leaves the blocks it rewires past.

A block qualifies when it has a single exit carrying that raise and every operation it holds satisfies can_remove_op — CanRemove (simplify.py:411-423), the predicate the dead-op pass would apply to those operations once the raise is gone. can_remove_op rather than is_pure_op: the question is what may be deleted, and inline.rs:1130-1135 already records that upstream keeps LLOp.is_pure() and CanRemove distinct for that reason.

Two other placements were tried and rejected by measurement

• Require the intermediate block to be empty. Disarms the change entirely — the raise blocks in this corpus build the exception. Back to three unrepairable constants_r entries and the in-process determinism failure.
• Widen the front's panic_block_is_pure_message so collapse_panic_message_chains normalises these raises — the phase whose own doc says it collapses panic chains "to the bare raise so remove_assertion_errors prunes the branch as it does for a direct implicit raise". Also disarms the change. Instrumenting the rejection path showed why: that phase runs after simplify_lowered_graph, and neither do_warn_explicit nor w_member_get_direct_kind ever presents an assert-raising block to it. Its 24 rejections across the corpus are all genuine side-effecting calls (handle_alloc_error, os::exit, core::intrinsics::unreachable), so widening its predicate buys nothing here.

The normalisation therefore belongs in the pass sequence that runs before remove_assertion_errors, which is where it now sits.

Generated code is unchanged

Against #1206's guard at the same base and corpus (af392b9a):

jitcodes.bin and descrs.bin are in HOST_ADDRESSED_OUTPUTS and are not comparable across processes, so the comparison is on the address-free fields.

Tests

majit-translate lib suite green (3193 passed). One new test pins both directions of the retarget predicate: a raise block holding only a ConstInt is retargeted and then pruned; one holding a getslice — outside CanRemove — keeps its edge and survives the pass.

Note on main's current CI

pyre/check.py is red on ubuntu and windows and the CPython gate is red, all of which predate #1206: main at b0f34c0af3e failed the same three jobs with byte-identical rows — wasm synth/exception_traceback_loop_forms guard_failures 810 -> 811 and cranelift synth/str_fstring 659 -> 658, cranelift 1 failed/424 passed, wasm 1 failed/417 passed. b0f34c0af3e re-recorded exception_traceback_loop_forms for dynasm and cranelift (811) and left wasm at 810. Not touched here.

— authored by Claude